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Simplified LDAP Access Control Language System 



BACKGROUND OF THE INVENTION 

TECHNICAL FIELD 

The invention relates to accessing information from a directory structure in a 
computer environment. IVlore particularly, the invention relates to controlling 
access to data within an LDAP directory structure in a computer environment. 

DESCRIPTION OF THE PRIOR ART 

A Lightweight Directory Access Protocol (LDAP) directory (such as Netscape 
Communications Corporation's Directory Server) is a collection of "entries." Each 
entry has a name (called the Distinguished Name) and a list of attribute values. 
The entries in a directory are organized In a tree structure, with major groupings 
that are subdivided into smaller units. A directory might contain several 
organization entries, each of which contains several organizationalUnit entries. 
These entries can be further subdivided. 

LDAP provides search operations that can be performed over specified portions of 
the directory tree. Trees and subtrees, therefore, are a natural way to deal with 
data stored in an LDAP directory. 

Entries and attributes con-espond to a wide variety of data types such as personnel 
information, server configuration, business relationships, and user preferences. 
Since all entries are stored within a single directory, a method is required to restrict 
the availability of specific information to authorized users. 
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The method used to control access is via Access Control Lists (ACL). The Directory 
Server Administrator (DSAdmin) creates some basic ACL rules that grant 
permission to certain users to access various information in the directory. Most of 
5 the security considerations will require from tens to hundreds of rules to 
implement. The smaller number of ACL rules offers better performance and easier 
manageability. 

Because a directory is the critical central repository In an Intranet containing 
10 collections of information, e.g., about people, it is imperative that a rich set of 
access options/features be provided. For example, the user should be able to 
modify his entry, or to update his home address or home phone number without 
any DSAdmin intervention. 

1 5 A better feature would be to give the user the ability to decide who can access 
some of his personal Information. The only way to do that Is to allow users to create 
ACLs. However, a directory can contain millions of entries such as the directory 
used by Netscape's Netcenter. To support this size of a directory using the 
traditional approach would require millions of ACLs which would not only degrade 

20 the server's performance but would also be highly unmanageable. It also creates a 
risk, i.e., the user can create a rule denying the DSAdmin some privileges which is 
unacceptable. 

Another disadvantage is that ACL syntax are generally complex. A normal user is 
25 unable to understand the format and fields of the rules to be able to use the rules 
effectively and safely. 

It would be advantageous to provide a simplified LDAP access control language 
system that gives the system administrator the ability to allow a user to specify a list 
30 of people that have access to certain attributes of that user's directory entry 
information. It would further be advantageous to provide a simplified LDAP access 
control language system that provides a simple mechanism to allow a user to make 
those specifications. 
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SUMMARY OF THE INVENTION 

5 The invention provides a simplified LDAP access language system. The system 
provides a simple command language that allows a system administrator to give a 
user the flexibility to specify a list of people that have access to certain attributes in 
a directory entry. In addition, the invention provides a system that allows a user to 
easily specify access lists without having to learn a complicated command syntax. 

10 

A preferred embodiment of the Invention provides user-defined attributes that tell 
the directory system who the user wants to give read or write access to a specific 
set of his attributes. The read and write attributes are separate lists and may. In 
fact, differ. This gives the user the flexibility to better manage access to his 
1 5 attributes. 

The value of the read and write attributes are in an LDAP Filter format which is an 
Internet standard (RFC 2254). The filter properties allow the user to specify not only 
users local to his intranet, but users across the Internet as well. 

20 

Access control lists (ACL) are created by the System Administrators. The ACLs list 
the specific attributes that the user is allowed to control read or write access. This 
gives the Administrators full control of what Infomnation the user can give out. 

25 The ACLs are stored in the directory along with the entries. When a user accesses 
an entry in a directory, the server checks the ACL specified for the attributes being 
accessed. The read or write attribute for the owner of the attributes being accessed 
are used by the server when it checks the ACL. The combination of the read or 
write attribute and the ACL determine whether the user has permission to perform 

30 the read or write access to the attribute being accessed. 
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Other aspects and advantages of the invention will become apparent fronn the 
following detailed description in combination with the accompanying drawings, 
illustrating, by way of example, the principles of the invention. 

5 

BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 is a diagram of an LDAP directory entry according to the invention; 

10 Fig. 2 is a schematic diagram of an example of how n attributes are accessed 
according to the invention; 

Fig. 3 is a block schematic diagram depicting the organization of users in a 
company hierarchical tree according to the invention; and 

15 

Fig. 4 is a block schematic diagram of a directory including ACLs, entries and 
read/write attributes according to the invention. 

20 DETAILED DESCRIPTION OF THE INVENTION 

The invention is embodied in a simplified LDAP access control language system in 
a computer environment. A system according to the invention provides a simple 
command language that allows a system administrator to give a user the flexibility 
25 to specify a list of people that have access to certain attributes in a directory entry. 
In addition, the invention provides a system that allows a user to easily specify 
access lists without having to learn a complicated command syntax. 

A Lightweight Directory Access Protocol (LDAP) directory (such as Netscape 
30 Communications Corporation's Directory Server) is a collection of "entries." Each 
entry has a name (called the Distinguished Name) and a list of attribute values. 
The entries in a directory are organized in a tree structure, with major groupings 
that are subdivided into smaller units. A directory might contain several 
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organization entries, eacli of which contains several organizationalUnit entries. 
These entries can be further subdivided. 

LDAP provides search operations that can be performed over specified portions of 
5 the directory tree. Trees and subtrees, therefore, are a natural way to deal with 
data stored in an LDAP directory. 

Entries and attributes correspond to a wide variety of data types such as personnel 
information, server configuration, business relationships, and user preferences. 
10 Since all entries are stored within a single directory, a method is required to restrict 
the availability of specific information to authorized users. 

The method used to control access is via Access Control Lists (ACL). The Directory 
Server Administrator (DSAdmin) creates some basic ACL rules that grant 
15 permission to certain users to access various information in the directory. Most of 
the security considerations will require from tens to hundreds of rules to 
implement. The smaller number of ACL rules offers better performance and easier 
manageabillty. 

20 Because a directory is the critical central repository in an intranet containing 
collections of information, e.g,, about people, it Is imperative that a rich set of 
access options/features be provided. For example, the user should be able to 
modify his entry, or to update his home address or home phone number without 
any DSAdmin intervention. 

25 

A better feature would be to give the user the ability to decide who can access 
some of his personal information. The only way to do that is to allow users to create 
ACLs. However, a directory can contain millions of entries such as the directory 
used by Netscape's Netcenter. To support this size of a directory would require 
30 millions of ACLs which would not only degrade the server's performance but 
would also be highly unmanageable. It also creates a risk, i.e., the user can create 
a rule denying the DSAdmin some privileges which is unacceptable, 
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Another disadvantage is that ACL syntax are generally complex. A normal user is 
unable to understand the format and fields of the rules to be able to use the rules 
effectively and safely. 

5 The problems that are presented are: 

• How to let users manage some of their own information. 

• How can the DSAdmin manage the information so that no security rules are 
violated. 

10 • How to make the server manageable under the above circumstances. 

Ideally, a DSAdmin would like to have rules that perform the following tasks (out of 
n attributes in a directory): 

15 1. Allow n1 attributes to be read by anyone In the world (this is a typical 
requirement). Example attributes are cn, sn, phonenumber. 

2. Allow n2 attributes to be read and modifiable by the user himself, e.g., home 
address, home phonenumber. 

3. Allow n3 attributes to be managed by an owner/manager, e.g., salary, 
20 employeegrade. 

4. Allow n4 attributes to be managed by the user, i.e., the user decides who can 
read or modify the attributes, For example, the user can decide that only Sam 
can read his hobbies attribute and only Kelly can read or change emergency 
contact info so that she can keep it up to date. 

25 5. Do not allow the rest n5= [n - (n1 + n2 + n3 + n4)] attributes to be accessible to 
the general public except for the Administrator group, e.g., employee status. 

Solving 1 , 2, 3 & 5 are fairly straightforward and will be explained below. The only 
difficult item is the 4th case. As previously mentioned, to enable this feature 
30 requires that the user be provided the ability to create his own ACLs. This could 
lead to millions of ACLs - which is not acceptable. The remainder of this document 
describes a novel approach to overcome these problems using a few ACLs and an 
existing Internet standard. 

6 
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One area where this is applicable is in Netscape's Netcenter which has a registry of 
Netcenter members. All of the member information is stored in a directory server. 
The Netcenter Administrators would not only prefer to maintain the member*s 
5 information/profiles but would also like to provide flexibility to allow members to 
maintain some other key information which other members can access. There is an 
immediate need with no current solution that can take care of this problem in an 
elegant way. 

10 One skilled in the art will readily appreciate that although LDAP directories are 
mentioned throughout, the invention can be implemented in any directory 
application. Additionally, although the examples cited concern attributes pertaining 
to people, one skilled in the art will readily appreciate that the invention can control 
access to any attributes stored in a system. 

15 

Referring to Fig. 1, an example of a person's LDAP directory entry 101 is shown. 
Attributes are listed that pertain to a particular individual. Some of these attributes 
are controlled by the Administrator 102, e.g., dn, sn, uld. A certain number of 
attributes 103 are the attributes that the user wants to control read and write access, 
20 e.g., hobbies, homepage, personalpage. 

The LDAP standard is very flexible. It allows extension of the schema by adding 
new attributes or objectclasses. One can add a new attribute called "hobbies" 107 
to an entry as long as the objectclass which has that attribute has been added. 

25 

With respect to Fig. 2, the ideal situation is when, given n attributes 201, some of 
the attributes are public 202, e.g., telephonenumber, where any user can see them. 
Other attributes are private and are not normally available to other users. For 
example, department admins and managers can only access a person's salary 
30 attribute 203 or only super admins can access a person's employee status 204. 
The final set of attributes are the ones that the user controls 205, e.g., hobbies, 
homepage, and personalpage. 
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The following ACL syntax is used to explain how cases 1, 2, 3, & 5 are solved. 
Note, the syntax is used for reference only. 

• Allow n1 attributes to be read by anyone: 

ACL: (list of n1 attrs) (allow ( read) user = "anyone") 

• Allow n2 attributes to be read/writeable by self: 

ACL: (list of n2 attrs) (allow (read, write) user = "self") 

• Allow n5 attrs to be read/writeable by the admin group only: 

ACL: (list of n5 attrs) (allow (read, write) group = "Admingroup") 

• Allow the owner or the manager to manage the n3 attributes: 

ACL:(list of nS attributes) (allow (read, write) attr="manager" or attr = 
"owner") 

Referring again to Fig. 1, user Prasanta's 108 manager is Claire 109 and 
she can read/write the list of nS attributes. Similarly, Joe's manager, Bill, can 
read/modify Joe's nS attributes. This Is achieved by using one ACL. The 
value of the "manager" is plugged in at runtime. 

For case 4, the requirements are more complex. Out of the n4 attributes, a finer 
granularity must be achieved, i.e., the n4 attributes can be read by certain people 
(n4-read attrs) and can be modified by certain people (not necessarily the same 
people that can read the attributes) (n4-write attrs). A preferred embodiment of the 
invention solves the 4th case by providing an ACL similar to the other cases, but 
also using user-defined attributes. 

Referring again to Fig. 1, the user-defined attributes 104 tell the system who the 
user wants to give permission to read 105 and write 106 to his attributes 103. It is 
evident that the read 105 and write 106 attributes are separate lists and may, in 
fact, differ. This gives the user the flexibility to better manage access to his 
attributes. 

The invention's ACL syntax is as follows (using the example discussed eariier): 
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ACL: (list of n4-read attrs) (allow (read) fllterattr= "whocanreadattr") 

Ex: (hobbles, emergencyContact) (allow (read) filterattr= " whocanreadattr ") 

ACL: ( list of n4-write attrs) (allow (write) filterattr= "whocanwriteattr" ) 
5 Ex: (emergencyContact) (allow (write) filterattr= " whocanwriteattr " ) 

where the values of a whocanreadattr & whocanwriteattr are: 

whocanreadattr: (((ldap:///o=abc.com?(uid=sam)) (uid=kelly)) 

10 

whocanwriteattr: (uid=keily) 

The value of the read and write attributes are in an LDAP Filter fornnat which is an 
Internet standard (RFC 2254). The ACLs are created by the DSAdmin. This gives 

15 the DSAdmin full control of what information the user can give out. With respect to 
Fig. 3, the filter properties allow the user to specify not only users local to his 
intranet, but users across the Internet as well. In the example above, Prasanta 303 
and Kelly 304 are users 302 in the same company, Netscape 301. The 
"whocanreadattr" gives Sam who is from ABC company and Kelly who is from 

20 Netscape, read access. 

Referring to Fig. 4, the ACLs 402 are stored In the directory 401 along with the 
entries 403. When a user accesses an entry 403 in a directory 401 , the server 
checks the ACL 402 specified for the attributes being accessed. The read 404 or 
25 write 405 attribute for the owner of the attributes being accessed are used by the 
server when it checks the ACL 402. 

Using the above example, the value of "whocanwriteattr" is plugged in by the server 
at runtime with "(uid=kelly)". So, if Kelly is the accessing client, the filter matches to 
30 TRUE and Kelly is allowed to modify the "emergencyContact" attribute. However, if 
Bill is the client, the filter matches to FALSE and Bill is denied the privilege. Each 
user can now create LDAP Filters which will allow them to manage their own 
information. 
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The advantages of the invention are: 

• The Admin has complete control of what a user can do. 
5 • Only a handful of ACLs are needed Instead of millions. 

• The performance of the server is markedly Increased. 

• The value of the new attributes are based on an Internet standard. 

Although the invention is described herein with reference to the preferred 
10 embodiment, one skilled in the art will readily appreciate that other applications 
may be substituted for those set forth herein without departing from the spirit and 
scope of the present invention. Accordingly, the invention should only be limited 
by the Claims included below. 
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CLAIMS 

1 . A process for a simplified access control language that controls access to 
5 directory entries in a computer environment, comprising the steps of: 

providing a user defined read list containing user identifications that are 
allowed to read a specified set of attributes; 

providing a system administrator defined read access control command; 

said read access control command listing the user attributes that said 
10 administrator has selected for user defined read access; and 

said read access control command referring to said user defined read list 
thereby allowing said read user identifications read access to said user attributes. 

2. The process of Claim 1, wherein upon a client read access, the directory 
15 server selects a specific read access control command according to the attribute 

being accessed and refers to the read list of the owner of the attribute being 
accessed to determine if said client has permission to execute said read access. 

3. The process of Claim 1 , further comprising the steps of: 

20 providing a user defined write list containing user identifications that are 

allowed to write a specified set of attributes; 

providing a system administrator defined write access control command; 
said write access control command listing the user attributes that said 
administrator has selected for user defined write access; and 
25 said write access control command referring to said user defined write list 

thereby allowing said write user identifications write access to said user attributes. 

4. The process of Claim 3, wherein upon a client write access, the directory 
server selects a specific write access control command according to the attribute 

30 being accessed and refers to the write list of the owner of the attribute being 
accessed to determine if said client has permission to execute said write access. 
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5. A process for a simplified access control language that controls access to 
directory entries in a computer environment, comprising the steps of: 

providing a system administrator defined read access control command that 
5 lists the user attributes that said administrator has selected for user defined read 
access; 

providing a system administrator defined write access control command that 
lists the user attributes that said administrator has selected for user defined write 
access; 

1 0 providing a plurality of user defined read lists containing user identifications 

that are allowed to read said user attributes that said administrator has selected for 
user defined read access; and 

providing a plurality of user defined write lists containing user identifications 
that are allowed to write said user attributes that said administrator has selected for 

1 5 user defined write access; 

wherein when a client read access to one of the user attributes that said 
administrator has selected for user defined read access occurs, said read access 
control command and the read list of the owner of the attribute being accessed are 
used to determine If said client has permission to execute said read access; and 

20 wherein when a client write access to one of the user attributes that said 

administrator has selected for user defined write access occurs, said write access 
control command and the write list of the owner of the attribute being accessed are 
used to determine if said client has permission to execute said write access. 

25 6. A process for a simplified access control language that controls access to 
directory entries in a computer environment, comprising the steps of: 

providing a user defined write list containing user identifications that are 
allowed to write a specified set of attributes; 

providing a system administrator defined write access control command; 
30 said write access control command listing the user attributes that said 

administrator has selected for user defined write access; and 

said write access control command referring to said user defined write list 
thereby allowing said write user identifications write access to said user attributes. 

12 
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7. The process of Claim 6, wherein upon a client write access, the directory 
server selects a specific write access control command according to the attribute 
being accessed and refers to the write list of the owner of the attribute being 

5 accessed to determine if said client has permission to execute said write access. 

8. The process of Claim 6, further comprising the steps of: 

providing a user defined read list containing user identifications that are 
allowed to read a specified set of attributes; and 
1 0 providing a system administrator defined read access control command; 

wherein said read access control command lists the user attributes that said 
administrator has selected for user defined read access; and 

wherein said read, access control command refers to said user defined read list 
thereby allowing said read user identifications read access to said user attributes. 

15 

9. The process of Claim 8, wherein upon a client read access, the directory 
server selects a specific read access control command according to the attribute 
being accessed and refers to the read list of the owner of the attribute being 
accessed to determine if said client has permission to execute said read access. 

20 

10. An apparatus for a simplified access control language that controls access to 
directory entries in a computer environment, comprising: 

a user defined read list containing user identifications that are allowed to 
read a specified set of attributes; and 
25 a system administrator defined read access control command; 

wherein said read access control command lists the user attributes that said 
administrator has selected for user defined read access; and 

wherein said read access control command refers to said user defined read 
list thereby allowing said read user identifications read access to said user 
30 attributes. 

11. The apparatus of Claim 10, wherein upon a client read access, the directory 
server selects a specific read access control command according to the attribute 
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being accessed and refers to the read list of the owner of the attribute being 
accessed to determine if said client has permission to execute said read access. 

12. The apparatus of Claim 10, further comprising: 
5 a user defined write list containing user identifications that are allowed to 

write a specified set of attributes; and 

a system administrator defined write access control command; 
wherein said write access control command lists the user attributes that said 
administrator has selected for user defined write access; and 

10 

wherein said write access control command refers to said user defined write 
list thereby allowing said write user identifications write access to said user 
attributes. 

15 13. The apparatus of Claim 12, wherein upon a client write access, the directory 
server selects a specific write access control command according to the attribute 
being accessed and refers to the write list of the owner of the attribute being 
accessed to determine if said client has permission to execute said write access. 

20 14. An apparatus for a simplified access control language that controls access to 
directory entries in a computer environment, comprising: 

a system administrator defined read access control command that lists the 
user attributes that said administrator has selected for user defined read access; 

a system administrator defined write access control command that lists the 
25 user attributes that said administrator has selected for user defined write access; 

a plurality of user defined read lists containing user identifications that are 
allowed to read said user attributes that said administrator has selected for user 
defined read access; and 

a plurality of user defined write lists containing user identifications that are 
30 allowed to write said user attributes that said administrator has selected for user 
defined write access; 

wherein when a client read access to one of the user attributes that said 
administrator has selected for user defined read access occurs, said read access 

14 
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control command and the read list of the owner of the attribute being accessed are 
used to determine if said client has permission to execute said read access; and 

wherein when a client write access to one of the user attributes that said 
administrator has selected for user defined write access occurs, said write access 
5 control command and the write list of the owner of the attribute being accessed are 
used to determine if said client has permission to execute said write access. 

15. An apparatus for a simplified access control language that controls access to 
directory entries in a computer environment, comprising: 

10 a user defined write list containing user identifications that are allowed to 

write a specified set of attributes; and 

a system administrator defined write access control command; 
wherein said write access control command lists the user attributes that said 
administrator has selected for user defined write access; and 
1 5 wherein said write access control command refers to said user defined write 

list thereby allowing said write user identifications write access to said user 
attributes. 

16. The apparatus of Claim 15. wherein upon a client write access, the directory 
20 server selects a specific write access control command according to the attribute 

being accessed and refers to the write list of the owner of the attribute being 
accessed to determine if said client has permission to execute said write access. 

17. The apparatus of Claim 15, further comprising: 

25 a user defined read list containing user identifications that are allowed to 

read a specified set of attributes; 

a system administrator defined read access control command; 
wherein said read access control command lists the user attributes that said 
administrator has selected for user defined read access; and 
30 wherein said read access control command refers to said user defined read list 
thereby allowing said read user identifications read access to said user attributes. 
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18. The apparatus of Claim 17, wherein upon a client read access, the directory 
server selects a specific read access control command according to the attribute 
being accessed and refers to the read list of the owner of the attribute being 
accessed to determine if said client has permission to execute said read access. 

5 

19. A program storage medium readable by a computer, tangibly embodying a 
program of instructions executable by the computer to perform method steps for a 
simplified access control language that controls access to directory entries In a 
computer environment, comprising the steps of: 

10 providing a user defined read list containing user identifications that are 

allowed to read a specified set of attributes; 

providing a system administrator defined read access control command; 
said read access control command listing the user attributes that said 
administrator has selected for user defined read access; and 
15 said read access control command referring to said user defined read list 

thereby allowing said read user identifications read access to said user attributes. 

20. The method of Claim 19, wherein upon a client read access, the directory 
server selects a specific read access control command according to the attribute 

20 being accessed and refers to the read list of the owner of the attribute being 
accessed to determine if said client has permission to execute said read access, 

21 . The method of Claim 19, further comprising the steps of: 

providing a user defined write list containing user identifications that are 
25 allowed to write a specified set of attributes; 

providing a system administrator defined write access control command; 

said write access control command listing the user attributes that said 
administrator has selected for user defined write access; and 

said write access control command referring to said user defined write list 
30 thereby allowing said write user identifications write access to said user attributes. 

22. The method of Claim 21, wherein upon a client write access, the directory 
server selects a specific write access control command according to the attribute 
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being accessed and refers to the write list of the owner of the attribute being 
accessed to determine if said client has permission to execute said write access. 

23. A program storage medium readable by a computer, tangibly embodying a 
5 program of instructions executable by the computer to perform method steps for a 

simplified access control language that controls access to directory entries in a 
computer environment, comprising the steps of: 

providing a system administrator defined read access control command that 
lists the user attributes that said administrator has selected for user defined read 
1 0 access; 

providing a system administrator defined write access control command that 
lists the user attributes that said administrator has selected for user defined write 
access; 

providing a plurality of user defined read lists containing user identifications 
15 that are allowed to read said user attributes that said administrator has selected for 
user defined read access; 

providing a plurality of user defined write lists containing user identifications 
that are allowed to write said user attributes that said administrator has selected for 
user defined write access; 
20 wherein when a client read access to one of the user attributes that said 

administrator has selected for user defined read access occurs, said read access 
control command and the read list of the owner of the attribute being accessed are 
used to determine if said client has permission to execute said read access; and 

wherein when a client write access to one of the user attributes that said 
25 administrator has selected for user defined write access occurs, said write access 
control command and the write list of the owner of the attribute being accessed are 
used to determine if said client has permission to execute said write access. 

24. A program storage medium readable by a computer, tangibly embodying a 
30 program of instructions executable by the computer to perform method steps for a 

simplified access control language that controls access to directory entries in a 
computer environment, comprising the steps of: 
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providing a user defined write list containing user identifications that are 
allowed to write a specified set of attributes; 

providing a system administrator defined write access control command; 
said write access control command listing the user attributes that said 
5 administrator has selected for user defined write access; and 

said write access control command referring to said user defined write list 
thereby allowing said write user identifications write access to said user attributes. 

25. The method of Claim 24, wherein upon a client write access, the directory 
10 server selects a specific write access control command according to the attribute 

being accessed and refers to the write list of the owner of the attribute being 
accessed to determine if said client has permission to execute said write access. 

26. The method of Claim 24, furiiher comprising the steps of: 

15 providing a user defined read list containing user identifications that are 

allowed to read a specified set of attributes; and 

providing a system administrator defined read access control command; 
wherein said read access control command lists the user attributes that said 
administrator has selected for user defined read access; and 
20 wherein said read access control command refers to said user defined read list 
thereby allowing said read user identifications read access to said user attributes. 

27. The method of Claim 26, wherein upon a client read access, the directory 
server selects a specific read access control command according to the attribute 

25 being accessed and refers to the read list of the owner of the attribute being 
accessed to determine if said client has permission to execute said read access. 
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